feat(scripts): script bundle import/export (#3245) - #3276

Summary

Implements #3245 (RMM-migration epic #3249): a versioned JSON script bundle format with export, preview, and import under /scripts/bundle/*, web UI on the Scripts page, and docs — so a script library can move between Breeze instances (or in from another RMM) carrying parameters, categories, tags, timeouts, run-as levels, and exit-code severity mappings instead of being pasted in one script at a time.

Plan: docs/superpowers/plans/open/2026-08-08-script-bundle-import-export.md · Spec: docs/superpowers/specs/onboarding-signup/2026-08-08-script-bundle-import-export-design.md

Security posture (the point of this PR)

A bundle is untrusted input whose contents run as SYSTEM on customer endpoints:

• Intake hardening (services/scriptBundle/schema.ts): the schema has no tenancy or trust fields — isSystem, id, orgId, partnerId, createdBy in an uploaded file are stripped and never read. parameters is bounded at intake (64KB serialized + depth 8) instead of inheriting the route schema's z.any() (whose 64KB cap is execute-time only). An all-null exitCodeSeverityMapping (never-alert) is rejected. Unknown bundleVersion is rejected, never best-effort parsed. Caps: 200 scripts/bundle, 256KB/content, 20MB body (new bodyLimit carve-out).
• isSystem can never come from a bundle, at any caller scope — stricter than POST /scripts. The importer never passes requestedIsSystem, and the clamp lives in the shared service (below), not the route.
• Partner-wide gate ([API][Security] POST /scripts allows partner-wide script creation without canManagePartnerWidePolicies — 'selected'-access users can push SYSTEM-level code to every org #3262/fix(api): gate partner-wide script writes on canManagePartnerWidePolicies (#3262) #3263 follow-through): the fix(api): gate partner-wide script writes on canManagePartnerWidePolicies (#3262) #3263 review flagged that canManagePartnerWidePolicies lived only in route handlers with no service-layer chokepoint, naming this importer as the likeliest path to reopen the privilege escalation. This PR extracts the POST /scripts tenancy resolution + capability gate + isSystem clamp into services/scriptWrite.ts and routes BOTH POST /scripts and the bundle importer through it. availability: 'partner' requires canManagePartnerWidePolicies(auth) and sets partnerId = auth.partnerId / orgId = NULL; the import/preview routes additionally fail fast with PARTNER_WIDE_WRITE_DENIED_MESSAGE (403) before touching any entry. Default availability is 'org'.
• No automations, schedules, or triggers are expressible in a v1 bundle, and import never executes anything.
• Audit: every imported/renamed/versioned script gets an individual script.bundle.import audit event tagged with the bundle's sha256, mode, and availability, so a later abuse finding traces to the import that introduced it. Imported rows are ordinary scripts rows, so the existing abuse-signal sweep covers them by construction.
• Export emits no tenancy identifiers and no isSystem — a round-trip cannot launder system scripts back in.

What's included

• API: GET /scripts/bundle/export?ids=…, POST /scripts/bundle/preview, POST /scripts/bundle/import (mode: skip | rename | new-version), mounted before the /:id routes; same scope/permission/MFA gating as the script write routes. Tag resolution by name in the target scope (reuse existing, create missing); new-version snapshots the previous content into script_versions before bumping. Per-entry failures are recorded and the rest proceed.
• Web: Export multi-select → download .json; import accepts a .json bundle, loose .ps1/.sh/.py/.bat files, or a folder (converted client-side — the server keeps one JSON intake). Preview table with conflict statuses, mode selector, partner-wide option gated on user.canManagePartnerWide, commit via runAction, and an explicit "scripts run as SYSTEM — trusted sources only" warning. i18n for all seven locales.
• Docs: bundle section in features/scripts.mdx (format, caps, unsigned-trust model).
• No new tables / no migrations — RLS, cascade, and export-policy registries are untouched by construction.

Tests

• services/scriptBundle/index.test.ts (20): schema hardening (strip/bounds/all-null mapping/version), import modes, tag resolution, tenancy-ignore, isSystem ignored even for a system-scope caller, service-level partner-gate denial, export cleanliness + schema round-trip.
• services/scriptWrite.test.ts (10): scope resolution matrix incl. the [API][Security] POST /scripts allows partner-wide script creation without canManagePartnerWidePolicies — 'selected'-access users can push SYSTEM-level code to every org #3262 gate; isSystem clamp incl. the no-option bundle path.
• routes/scriptBundle.test.ts (11): 403 for a non-capability partner user importing availability:'partner' (nothing written), org-scope 403, partner-wide row shape for a full-partner admin, default-'org', isSystem/tenancy strip over HTTP, unknown version 400, per-script audit with sha256, export shape, preview gate.
• middleware/bodyLimit.test.ts: 20MB carve-out.
• Web: lib/scriptBundle.test.ts (8) for loose-file conversion; locale parity + translation coverage green.

Local results: API affected suite 98 passed / 2 pre-existing skips (single-fork); web 71 passed; tsc --noEmit clean for both apps/api and apps/web; eslint clean on changed files.

Note: routes/scripts.execute-schema.test.ts crashes at import in this dev environment on clean main too (Node 20 vs required 22 toolchain issue) — unrelated to this change; CI runs it normally.

Known gaps / follow-ups

• apps/docs/.../migration/toolkit.mdx (Recipe 6 replacement, plan Task 8) lives on the unmerged docs branch (PR docs(migration): RMM-to-Breeze migration guides #3250), not main — it should be updated there once these routes land.
• Category travels as the scripts.category varchar (by name); the script_categories hierarchy table is not populated by import (the real scripts routes don't use it either — the hierarchical library routes are still mock-backed).

Closes #3245

🤖 Generated with Claude Code